Modern vehicles have multiple dedicated computers called “electronic control units” (ECUs). These ECUs control various aspects of the vehicle's operation, e.g., by controlling the vehicle's engine, breaking and steering, and entertainment systems. The ECUs are connected to each other, over a bus, in a network that typically uses a version of the Controller Area Network (CAN) bus protocol. Version 2.0 of this protocol is described in a document entitled CAN Specification, version 2.0, published in 1991 by Robert Bosch GmbH, which is incorporated herein by reference. Another version of this protocol, CAN with Flexible Data-Rate (CAN FD), is described in a document entitled CAN with Flexible Data-Rate, Specification version 1.0, published in 2011 by Robert Bosch GmbH, which is incorporated herein by reference.
An ECU typically comprises a processor, such as a microcontroller, which is a programmed digital computing device typically comprising a central processing unit (CPU) and a random access memory (RAM). Typically, the processor runs firmware or software. An ECU typically further comprises a “CAN controller” and a “CAN transceiver,” which collectively implement the CAN bus protocol and handle communication over the CAN bus. The CAN controller may be part of, or separate from, the processor.
Per the CAN bus protocol, the ECUs broadcast multi-bit messages (or “frames”) over the bus. The CAN bus protocol is a synchronous protocol, in which time is split into bit-time slots. (For example, on a 1 Mbps network, each bit-time slot is 1 μs long.) During each bit-time slot, there can be only one bit value on the bus. Whenever two ECUs attempt to broadcast different bits during the same bit-time slot, a “collision” occurs. In such a situation, the dominant bit overwrites, or “trumps,” the recessive bit, such that the dominant bit, rather than the recessive bit, is carried by the bus. The ECU that broadcasted the dominant bit may be said to have “won” the collision, while the other ECU may be said to have “lost” the collision.
In typical implementations, the CAN bus protocol designates the “zero” bit as dominant and the “one” bit as recessive; in other implementations, the reverse designation may be used. To help maintain synchronization, a bit stuffing is applied, whereby, after every five consecutive bits of the same value, a bit of the opposite value is inserted. (This bit stuffing is not applied to error messages or to some fixed-content fields such as the end-of-frame (EOF) field, each of which may include more than five consecutive bits of the same value, as further described below.)
Some messages, known as “data frames,” include several fields. In at least some versions of the CAN bus protocol, these fields include (i) a one-dominant-bit start-of-frame (SOF) field at the start of the message, (ii) a message ID field, having 11 or 29 bits, that indicates the type of the message (and hence, typically, the ECU from which the message originated), (iii) a four-bit data length code (“DLC”) field, which stores the length of the subsequent data field, and (iv) a data field. (Data frames may include several other fields that are not referenced below, and are therefore not mentioned here.) In at least some versions of the CAN bus protocol, each successfully-transmitted data frame ends with 8+3 consecutive recessive bits, comprising a one-recessive-bit Ack delimiter (ADel) field and a seven-recessive-bit EOF field, followed by a three-recessive-bit intermission (IS) field. Immediately following the IS field, another message may be transmitted over the bus.
While attempting to broadcast each bit in a message, the ECU also monitors the bus, to check if the attempted broadcast was successful. If the broadcast was not successful, i.e., the actual value on the bus is different from that which the ECU attempted to broadcast, the ECU identifies a “bit-error.” In response, the ECU may stop broadcasting the message, and may further broadcast an error flag, and/or increment its transmit error counter (TEC). (In general, the behavior of the ECU following an unsuccessful broadcast varies, depending on several factors such as the field to which the interrupted bit belongs.) If the ECU is in a normal operating state, referred to as the “error-active state,” the broadcasted error flag is an “active-error flag,” which consists of six dominant bits followed by eight recessive delimiter bits.
Upon the TEC of an ECU reaching a first threshold value of 128, the ECU leaves the error-active state, and enters the “error-passive state.” In this state, the ECU is not allowed to broadcast an active-error flag; instead, upon identifying an error, the ECU must broadcast a passive-error flag, which consists of six recessive bits in lieu of the six dominant bits of the active-error flag, followed by the eight-recessive-bit delimiter. (Passive-error flags are generally recessive to all other messages broadcast on the network, in that these flags include only recessive bits.) Typically, in practice, the ECU does not actually broadcast the first six recessive bits; rather, the ECU broadcasts the eight-recessive-bit delimiter following the identification, by the ECU, of six consecutive recessive bits on the bus. Other broadcasting rights of the ECU may also be restricted in the error-passive state; for example, the ECU may be required to broadcast eight recessive bits following the end of the intermission of a previous message, before gaining the right to broadcast a new message.
An ECU may have its TEC reduced by one, following each successful broadcast of a message; hence, following a sufficient number of successful broadcasts, the ECU may exit the error-passive state, and return to normal broadcasting. If, however, the TEC of the ECU reaches a second threshold value of 256, the ECU enters the “bus-off state,” in which the ECU is disabled, and is not allowed to broadcast at all.
In one type of spoofing attack, an attacker obtains control of one of the ECUs, and uses this subverted ECU to impersonate another one of the ECUs, by broadcasting, over the network, impersonating messages that appear to originate from the other one of the ECUs.
The following academic articles describe attacks on CAN networks, and/or methods for defending against such attacks:    (i) Matsumoto, Tsutomu, et al., “A method of preventing unauthorized data transmission in controller area network,” Vehicular Technology Conference (VTC Spring), 2012 IEEE 75th. (pp. 1-5);    (ii) Kurachi, R., et al., “CaCAN-Centralized authentication system in CAN,” Proc. ESCAR 2014 Europe Conference, Hamburg, Germany, 2014;    (iii) Kurachi, R., et al., “SecGW secure gateway for in-vehicle networks,” 13th Int. Conf. on Embedded Security in Cars (ESCAR 2015);    (iv) Ujiie, Yoshihiro, et al., “A method for disabling malicious CAN messages by using a CMI-ECU,” No. 2016-01-0068, SAE Technical Paper, 2016;    (v) Cho, Kyong-Tak, and Shin, Kang G., “Error handling of in-vehicle networks makes them vulnerable,” Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, ACM, 2016.